\section{Related Work}
\label{sec:RelatedWork}
In \cite{XACMLPolicyEngineofUCON}:
\begin{itemize}
 \item Attribute class identifier has been introduced to distinguish between mutable and non mutable attributes (pre-mutable, ongoing-mutable, post-mutable).
 \item Rules are classified into the rules that have to be evaluated for pre/on authorizations.
 \item For obligations and conditions expressions: evaluation-phase is added to denote obligations and conditions related to pre-access and ongoing-access.
\end{itemize}
In \cite{ContinuousUsageControlFeatures} \& \cite{Prototype}
\begin{itemize}
 \item To handle decision continuity, the authors have added the DecisionTime in the condition element (pre and ON).
 \item To handle mutability of attributes, <AttrUpdates> is added to handle the attribute update. <AttrUpdates> contains UpdateTime that has the value pre/on 
 which mentions if the update has to be done before or after the access.
 \item Introduction of a retrieval policy which mentions where the attributes have to be retrieved for update.
\end{itemize}

In \cite{DBLP:conf/noms/Lischka10}

In \cite{DBLP:conf/codaspy/LiCB12}, the architecture proposed is like the following: there are two main components:
\begin{itemize}
 \item Access Control Component (ACC): can be implemented independently of the underlying applications
 \item External Environment (EE): describes the applications running environment and how to interact 
 with the ACC, it contains Obligation modules to handle specific functionalities. The modules interact with the PEP through event interfaces.
\end{itemize}

Obligations are modeled as state machines that interact with the outside world through events. 
All the states are predetermined. Events are grouped into 3 different families.

\begin{itemize}
\item \textbf{PEP-notification:} These events are related to the status of handling access requests (after the PDP returns permit or deny)
\item \textbf{PEP-session:} These events state if an access session has started or ended
\item \textbf{Timer:} These events are sent between the PEP and the obligations to state that an obligation has to cancel some request
\end{itemize}
An Obligation is composed of:
\begin{itemize}
 \item \textbf{FulfillOn}: Same meaning as defined in XACML v3.0 however the authors have added the support of fulfilling on error and applicable besides 
 permit and deny.
 \item \textbf{A boolean variable}: This indicates whether the obligation is optional or not. 
 \item \textbf{List of event families}: This specifies the different families that an obligation may receive and what kind of events it is going to generate.
 \item \textbf{A starting state}. 
 \item \textbf{One or more rule sets}: The rules are associated to the states and are similar to XACML rules; they contain an effect that mentions 
 the next state related to the current state of the obligation.
\end{itemize}

The PEP has a current state for each obligation. Obligations are processed through events.
Depending on the current state of each obligation, the PEP will choose a set of rules and then will evaluate the rules against the event.


